Avoid per-row queries for evolution condition variables and natures - #1690

Problem

PokemonEvolutionSerializer.get_condition_expression and get_allowed_natures run one query per PokemonEvolution row. Milcery → Alcremie has 63 evolution rows, each with a condition_expression, so /evolution-chain/452/ takes 65 queries (63 of them to pokemon_v2_evolutionvariable).

Fix

Both tables are tiny (4 evolution variables, 25 natures). Each is loaded and serialized once, lazily, through a cached_property on the serializer instance, and each row picks its entries in Python, keeping the previous ordering. Variables are kept as (symbol, data) pairs rather than a dict, since symbol isn't unique across version groups. ListSerializer reuses a single child instance for every row, so this is one query per list of evolution details instead of one per row, and no state is shared across requests.

Verification

• Built the DB from the CSVs and serialized all 540 evolution chains before/after: byte-identical JSON for every chain, chain 452 drops from 65 to 3 queries (and its serialization from ~52 ms to ~32 ms locally, by not re-running the summary serializers per row), and no chain needs more. OpenAPI schema unchanged.
• Added a test that builds chains with 1 and 5 evolution rows (each with a condition_expression and nature_bitmask), asserts the query count is the same, and checks the resolved variables and natures. This is the first API test coverage for these two fields. It uses cachalot_disabled(), because inside the test transaction cachalot serves identical repeated queries from memory, which hides per-row queries. On master this test fails with 13 vs 5 queries.
• manage.py test pokemon_v2 (64 tests), ruff, and ty (no new diagnostics) pass.
• In production cachalot/Redis caches these queries, so the gain is mainly for cold-cache requests and fewer cache round-trips.
• Touches the same file as Fix N+1 query in evolution chain serializer #1688; whichever lands second will need a trivial rebase.